Secure system and method for SAN management in a non-trusted server environment

ABSTRACT

According to the present invention a method and a system is provided for operating a storage area network (SAN) in a server environment in which multiple servers share one Fibre Channel adapter. A SAN Management Server manages regions in storage systems and security, a Fiber Channel Network provides a connection to storage devices, and a plurality of Operating System Images run in said server environment. Furthermore, a trusted SAN Management Client Unit is connected to said SAN Management Server and a Fiber Channel adapter is configured to authenticate said trusted SAN Management Client Unit, whereby the trusted SAN Management Client Unit is configured to issue commands in said Fiber Channel Network in place of each of said Operating System Images.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to storage area networks.Particularly, the present invention relates to a method and a system foroperating a storage area network in a server environment in whichmultiple servers share one Fibre Channel adapter.

2. Description of the Related Art

Fibre channel is a high speed, full-duplex, serial communicationstechnology used to interconnect input/output (I/O) devices and hostsystems that can be separated by tens of kilometers. It incorporates thebest features of traditional I/O interfaces, like throughput andreliability found in SCSI and PCI, with the best features of networkinginterfaces, like connectivity and scalability found in Ethernet andToken Ring. It provides a transport mechanism for the delivery ofexisting commands, and provides an architecture that achieves highperformance by allowing a significant amount of processing to beperformed in hardware. It can operate with legacy protocols and driverslike SCSI and IP, enabling it to be introduced easily into existinginfrastructures.

Fibre channel transfers information between the sources and the users ofthe information. This information can include commands, controls, files,graphics, video and sound. Fibre channel connections are establishedbetween Fibre channel ports residing in I/O devices, host systems, andthe network interconnecting them. The network consists of elements likeswitches, hubs, bridges and repeaters that are used to interconnect theFibre Channel ports.

There are three Fibre Channel topologies defined in the Fibre Channelarchitecture. These are Point-to-Point, Switched Fabric and ArbitratedLoop.

Fibre channel switches (or switched fabrics) also include functionscommonly called Zoning. These functions allow the user to partition theswitch ports into port groups. The ports within a port group, or zone,can only communicate with other ports in the same port group (zone). Byusing zoning, the I/O from one group of hosts and devices can becompletely separated from that of any other group, thus preventing thepossibility of any interference between the groups.

This is also referred to as “soft zoning”. The way this soft zoningworks is that the user assigns nodes to a zone according to the node'sWorld Wide Name—either the World Wide Port Name (WWPN) or the World WideNode Name (WWNN). The name server captures this information, which is afunction embedded within the switch. Then, whenever a port communicateswith the name server to find out to which nodes it is allowed toconnect, the name server will respond only with the nodes that arewithin that port's zone.

Since the standard Fibre Channel device drivers do communicate with thename server in this manner, this type of zoning is adequate for mostsituations. However, it is possible that a device driver could bedesigned that would attempt to access nodes not in its list of allowedconnections. If this occurred, the switch would neither prevent nordetect the violation.

In order to prevent this case, switches also optionally implement amechanism called “hard zoning” in addition to soft zoning, where theswitch network decides based solely on source and destination address ofeach frame if this frame is allowed to be transported.

Fiber channel Storage Area Networks (SANs) are networks that connectstorage devices to host servers. They are built upon the Fibre Channeltechnology as a networking infrastructure. What differentiates SANs fromprevious interconnection schemes is the basic concept that all (ormostly all) of the storage can be consolidated in one large “storagearea” that allows centralized (simplified) management in addition toany-to-any connectivity between host servers and the storage.

Fibre channel SANs have the potential to allow the interconnection ofopen systems and storage (i.e., non-zSeries) in the same network aszSeries systems and storage. This is possible because the protocols forboth open attachment and zSeries attachment are being mapped to the FC-4layer of the Fibre Channel architecture.

In Fibre Channel attachments, LUNs have an affinity to the host's FibreChannel adapter (via the adapter's World Wide Unique Identifier, a.k.a.the World Wide Port Name), independent of which ESS (IBM EnterpriseStorage Server) Fibre Channel port the host is attached to. Therefore,in a switched fabric configuration where a single Fibre Channel host canhave access to multiple Fibre Channel ports on the ESS, the sets ofLUNs, which may be accessed by the Fibre Channel host, are the same oneach of the ESS ports.

One result of this implementation is that with Fibre Channel, unlike inSCSI, hosts that are attached to ESS via a fabric to the same FibreChannel port may not be able to “see” the same LUNs, since the LUNmasking can be different for each Fibre Channel host. In other words,each ESS can define which host has access to which LUN.

Another method is to create zones in the switch such that each FibreChannel port from each host is constrained to attach to one FibreChannel port on the ESS, thereby allowing the host to see the LUNs viaone path only.

Details of the Fibre Channel specification are shown in the followingstandards: Fibre Channel Physical and Signaling Interface (FC-PH), ANSIX3.230-1994; Fibre Channel Second Generation Physical Interface(FC-PH-2), ANSI X3.297-1997; Fibre Channel Third Generation PhysicalInterface (FC-PH-3), ANSI X3.303-199x, Revision 9.4 and Fibre ChannelArbitrated Loop (FC-AL), ANSI X3.272-1996. Further relevant standardsare FC-FS, FC-GS-3.

Further information concerning the Fibre Channel is disclosed in TheFibre Channel Consultant—A Comprehensive Introduction (Robert W. Kembel,1998) and The Fibre Channel Consultant—Arbitrated Loop (Robert W.Kembel, 1996).

EP 1 115 225 A2, by Barry Stanley Barnett et al., assigned toInternational Business Machines Corporation, Armonk, N.Y., US, filedDec. 22, 2000, published Jul. 11, 2001, “Method and system forend-to-end problem determination and fault isolation for storage areanetworks” discloses a method and system for problem determination andfault isolation in a storage area network (SAN). A complex configurationof multi-vendor host systems, FC switches, and storage peripherals areconnected in a SAN via a communications architecture (CA). Acommunications architecture element (CAE) is a network-connected devicethat has successfully registered with a communications architecturemanager (CAM) on a host computer via a network service protocol, and theCAM contains problem determination (PD) functionality for the SAN andmaintains a SAN PD information table (SPDIT). The CA comprises allnetwork-connected elements capable of communicating information storedin the SPDIT. The CAM uses a SAN topology map and the SPDIT are used tocreate a SAN diagnostic table (SDT). A failing component in a particulardevice may generate errors that cause devices along the same networkconnection path to generate errors. As the CAM receives error packets orerror messages, the errors are stored in the SDT, and each error isanalyzed by temporally and spatially comparing the error with othererrors in the SDT. If a CAE is determined to be a candidate forgenerating the error, then the CAE is reported for replacement ifpossible.

US 2001/0054093 A1, by Sawao Iwatani, Kawasaki, Japan, filed Feb. 9,2001, published Dec. 20, 2001, “Storage area network management system,method, and computer-readable medium” discloses an integrated managementmechanism of a storage area network (SAN) integrating and managing atraditionally dispersed security system from a single source andautomates security management in the SAN. The integrated managementmechanism integrates and manages the SAN, and is configured so thataccess relationships of the host computers and the storage devices ofthe SAN are managed using the integrated management mechanism. An accesspath on the integrated management mechanism, including a region of thestorage devices to which access is attempted from the host computer, thefiber channel adapters used when accessing that storage, and the hostbus adapters (HBA) are configured. Based on the access path informationconfigured, the integrated management mechanism establishes respectivestorage settings, zoning settings, and accessible region permissions fora SAN management mechanism of the host computer, a zoning settingsmechanism of the switch, and a storage management mechanism of thestorage device.

OBJECT OF THE INVENTION

Starting from this, the object of the present invention is to provide amethod and a system for operating a storage area network in a serverenvironment, in which multiple server share one Fibre Channel adapter,having an improved security mechanism.

BRIEF SUMMARY OF THE INVENTION

The foregoing object is achieved by a method and a system as laid out inthe independent claims. Further advantageous embodiments of the presentinvention are described in the sub claims and are taught in thefollowing description.

According to the present invention a method and a system is provided foroperating a storage area network (SAN) in a server environment in whichmultiple servers share one Fibre Channel adapter. A SAN ManagementServer manages regions in storage systems and security and/or detectingerrors and configuring the SAN, a Fiber Channel Network provides aconnection to storage devices, and a plurality of Operating SystemImages run in said server environment. Furthermore, a trusted SANManagement Client Unit is connected to said SAN Management Server and aFiber Channel adapter, whereby the trusted SAN Management Client Unit isconfigured to issue commands in said Fiber Channel Network in place ofeach of said Operating System Images.

In a preferred embodiment of the present invention, the serverenvironment includes virtual servers and/or partitioned servers.

Preferably, the SAN Management Server is configured to distinguish afirst set of commands and a second set of commands, whereby the firstset of commands are processed by the SM Client together with said SAN,and whereby said second set of commands are processed by said OS Imageswithout access to said SAN. Favorably, the Fiber Channel adapter (FCadapter) is configured to authenticate said trusted SAN ManagementClient Unit.

Advantageously, the FC adapter and said SAN may be adapted to restrictthe access of the untrusted OS Images to the minimal necessary set ofcommands. Alternatively, the FC adapter and a virtualization layer ofthe virtual server may be adapted to restrict the access of theuntrusted OS Images to the minimal necessary set of commands.

In another embodiment of the present invention, only one SM Client isprovided in order to keep the server load small. Optionally, one or morebackup SM Clients are provided to provide redundancy.

Advantageously, only the SM Client is registered for receiving messagesfrom the SAN and the SM Client is configured to forward said messagesonly to said SM Server. Optionally, the FC Adapter is configured toforward all messages for which a registration is not necessary solely tothe SM Client and not to the untrusted OS Images.

In a different embodiment of the present invention the server isequipped with two classes of agents, namely, the SM Client and a RemoteAccess Server (RA Server). Preferably, the server is equipped withrepository for keeping authorization data for accessing the RA Server.

Preferably, only the SM Client and the FC adapter are configured togather information used for billing the use of resources by eachuntrusted OS Image. Advantageously, the SM Framework is adapted tocommunicate with a Firewall control application, in order to set theaccess rights.

In a further embodiment of the present invention the SM Client isadapted to function as a router for the requests from the SM server tothe RA server. Preferably, an existing telnet/sshd server forms the RAServer.

Furthermore, the present invention may be implemented as a method foroperating a storage area network (SAN) in a server environment in whichmultiple operating system images share one Fibre Channel adapter, inwhich the SAN is managed by a SAN Management software with at least aSAN Management server and at least a SAN Management client with acommunication path to said Fibre Channel Adapter. The requests issued bythe SAN Management server are separated into at least two groups,namely, a first group is processed by the Fibre Channel adapter and theSAN on behalf of the SM client in place of other operating systems whichshare the same adapter, corresponding to a trusted path, and a secondgroup is processed by the other operating systems without the need tosend or receive requests to or from the FC adapter and the SAN.

In a preferred embodiment of the method all information contained inunsolicited messages generated in the SAN and FC adapter are routed tothe SAN Manager by the SAN management client. Preferably, the HBA_APIbinding requests are used to modify the firewall.

Optionally, the communication path from the SAN Management client to theadapter is operated so that it cannot be modified or eavesdropped byanother operating system image. In a further preferred embodiment allinformation relevant for billing individual operating system images aregenerated in the adapter and are routed through the SAN to the SANManager by the SAN client on the trusted path.

Advantageously, the SM server provides authorization data to the SMclient to execute requests from said first group. Optionally, SM serverand SM client provide authorization data to the other OS images toexecute requests from said second group. Preferably, the OS images areoperated so that they are only enabled to execute a limited command setin the SAN.

A large number of operating systems (>256, 4000 virtual servers arelikely in 2004) have to participate in a SAN with shared FC adapters.Adapters are shared in this type of scenario because of cost reasons andmanageability reasons. A server with 256 FC adapters needs for example256 cables from the adapters to the switch and 256 ports in the switchnetwork.

In a server hosting environment each OS image needs private data, whichmay not be accessed by other OS images (for example the serverconfiguration) and shared read-write data, for example a shared databaseshared read only data, for example, a preinstalled operating systemimage (/usr in a unix system) for LUNs shared by OS images by the sameadapter it is not possible to guarantee a completely scsi compliantbehavior (for example reserve/release, NACA handling, queuing rules asdefined by SAM-2).

Each “untrusted operating system image” is owned by a potentiallydangerous entity, for example two companies who compete with each otheror a hacker. Owned means the entity that actually has root access andcan alter every piece of the operating system image including all SMclients or other software. The OS image owner has no access and cannotmodify hardware on its own behalf but needs the machine owner to dothis. The machine owner (IT department/ASP/ISP) has full control aboutall hardware, mappings and policies in the SAN. The machine ownerassigns resources in the SAN (most probably LUNs in a disk controller)to the operating system images. The machine owner needs a tool toperform Error Detection and Fault Isolation in the SAN to preventdowntime of operating system images. The machine owner might want tosplit its hardware into multiple entities and subnets, which can bemanaged independently from other subnets (group multiple servers orLPARs) A shared adapter does not span subnets, but may span LPARs.

Each OS image is either run on a individual server (blade server) or asa virtual server. Virtual Server environments can be created by forexample LPAR-zSeries firmware, the zSeries VM operating system or VMwareon Intel based servers).

The presentation of SAN resources in the SAN Manager user interfaceshould be done in such a way that the machine owner can move a OS imagefrom a virtual server to a physical server without getting a completelydifferent kind of view presented by the SM server user interface.

The access of each OS image can be restricted by a firewall in the FCadapter or an other entity, which does not belong to the OS image(otherwise a user with root access rights who has complete control overthe OS image has the ability to circumvent it).

The FC to SCSI mapping in each untrusted OS image can be configured by aFC device driver mapping and configuration interface MAP_IF. For examplethe MAP_IF on certain versions of Fiber Channel on zSeries isimplemented by a Linux specific configuration method calledproc-file-system to set and query said mapping. The SM server should notrely on correct data reported by a MAP_IF (access enforcement is done byfirewall, so either the OS cooperates or won't see any data at all).Measurements for billing cannot be done in the untrusted OS images(because the root user is free to modify the data). Therefore theadapter or other entities have to provide the required measurement data.

Other embodiments may provide multiple WWPNs although the number ofWWPNs might be lower than the number of supported OS images per adapter.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The above, as well as additional objectives, features and advantages ofthe present invention, will be apparent in the following detailedwritten description.

The novel features of the invention are set forth in the appendedclaims. The invention itself, however, as well as a preferred mode ofuse, further objectives, and advantages thereof, will best be understoodby reference to the following detailed description of an illustrativeembodiment when read in conjunction with the accompanying drawings,wherein:

FIG. 1 shows a block diagram illustrating a first embodiment of a systemaccording to the present invention;

FIG. 2 shows a block diagram illustrating a second embodiment of thesystem according to the present invention;

FIG. 3 shows a flow chart illustrating the method for operating astorage area network in a server environment in which multiple serversshare one Fibre Channel adapter according to the present invention;

FIG. 4 shows a flow chart illustrating simplified signals and flow forthe aforementioned type of fabric related HBA_API commands;

FIG. 5 shows a flow chart illustrating simplified signals and a flow forthe aforementioned type of FCP to SCSI mapping HBA_API commands; and

FIG. 6 shows a flow chart illustrating simplified signals and a flow forthe aforementioned type of HBA_API commands to handle ELS requestsinitiated by the SAN.

DETAILED DESCRIPTION OF THE INVENTION

With reference to FIG. 1, there is depicted a block diagram illustratinga first embodiment of a system 100 according to the present invention.The system 100 comprises multiple computer systems 104, 105 and 106, allbeing adapted to access a SAN 110 via one common Fibre Channel adapter112 having WWPN 1 (World Wide Port Name). For the sake of clarity onlythree computer systems are depicted. It is acknowledged that the numberof computer systems may be in the hundreds or even in the thousands.Having such a high number of computer systems, more than one FibreChannel adapter may be present in the system, however, even in this casea plurality of computer systems would share one and the same FibreChannel adapter.

As a gateway between each of the computer systems 104, 105 and 106 andthe Fibre Channel adapter a firewall 114, 115 and 116 is provided,respectively, for ensuring that each of the computer systems is onlyenabled to access permitted portions of the SAN 110. The firewalls 114,115 and 116 may be integrated in the Fibre Channel adapter or attachedto it. On the other hand, all computer systems 104, 105 and 106 areconnected to a network 120, such as an Ethernet network.

Furthermore, the system 100 comprises two more computer systems 122 and123 being connected to the network 120, hosting a SAN Management Server130 (SM Server) running on an operating system (OS) 131 and a SANManagement Client 132 (SM Client), respectively. The SM Server 130 runsthe server portion of a SAN Management System, e.g., Tivoli StorageNetwork Manager (http://www.tivoli.com/products/index/storage_net_mgr/),whereas the SM Client 132 runs the respective client portion of suchsystem.

The SM Server 130 is further connected to a firewall control application134 via a communication line, whereas the SM Client 132 has got acommunication link to the Fibre Channel adapter 112. The firewallcontrol application 134 is provided with communication links to each ofthe firewalls 114, 115 and 116, either through the Fibre Channel adapter(as depicted) or directly to each of them.

The SM Server 130 accesses each of the computer systems 104, 105 and 106via a respective Secure Shell Interface 144, 145 and 146, i.e., aprogram for logging into, and executing commands on, a remote computer.A mapping interface MAP_IF 154, 155, 156 provided in each computersystem 104, 105 and 106 takes care about the Fibre Channel to SCSI(Small Computer System Interface) mapping. This can for example beimplemented as a command line interface or a configuration file.

Each computer system 104, 105 and 106 runs an operating system 164, 165and 166, which may be “untrusted.” “Untrusted” in this context meansthat the operating system may be controlled or manipulated by apotentially dangerous entity, e.g., a piece of malicious code, such as acomputer virus or a person trying to tamper the operating system inorder to access or alter information in the SAN, which should beunreachable for said entity. The operating system itself may be formedby any of a wide variety of operating systems, such as AIX or z/OS byInternational Business Machines Corporation, UNIX and Linux.

Since the security mechanism in accordance with the present inventiontake into consideration that an unauthorized SAN access request may beissued by any one of the computer systems 104, 105 and 106, therespective firewall 114, 115 and 116 filters all SAN access requests andonly accept those authorized by the firewall control application. Onlythe firewall control application 134, which is not accessible by any ofthe computer systems 104, 105 and 106, is enabled to modify firewallsettings specifying authorized SAN access requests. According to thefirst embodiment of the present invention, the SM Server 130 controlsthe firewall control application 134.

The SM Client 132 runs on top of the HBA_API 168 (Host Bus AdapterApplication Program Interface) on top of an operating system 170, whichhas to be “trusted,” i.e., the operating system is managed by an entitynot intending to temper SAN access rights or the like. The Fibre Channeladapter 112 is adapted to distinguish untrusted and trusted operatingsystems. This authorization can be accomplished by identifying theoperating system 170 or the SM Client 132 by some means of well-knownauthorization schemes like fixed source addresses (for example hardwareIDs), keys and cryptographic algorithms, or passwords, which are notpart of this invention. Requests related to crucial Information, such asSAN configuration, SAN components, SAN access rights, error messages,statistics or billing information may only be accepted coming from thetrusted operating system 170 running the SM client 132. Correspondingly,the results to such requests are only returned to the trusted operatingsystem 170. In other words, the SM Client 132 controlled by the SMServer and acting in place of the untrusted operating systems solelyperforms the SAN management.

The SM server 130 comprises a SM core engine (not shown), which issuesrequests in order to query and set information in the SAN and in themanaged operating systems and a communication module (not shown), whichroutes the requests and responses from the core engine to the clients.The communication module can either be implemented as part of the SMserver or be distributed over the SM server and SM client components,which reside in “trusted” environments.

The secure shell daemon sshd and the OS specific FC configurationinterfaces are summarized as RA (Remote Access) server. The remoteaccess server is adapted to respond to authorized requests sent by a SMserver or SM client. In a preferred implementations the SM client andthe RA server uses authorization data such as passwords, user-ids andcryptographic keys to identify the originator of the requests.Therefore, the communication module is equipped with a repository (notshown) for said authorization information. The communication moduleseparates fabric related requests, i.e., requests for managing the SAN,and adapter related requests, i.e., requests for managing the FibreChannel adapter, from the OS specific requests according to the list ofcommands below. As aforementioned, the connection between the SM server,the SM client and RA server is an IP based network, which runs on, e.g.,Ethernet. In a different embodiment some communications between the SMclient, SM server and RA Server could utilize the FC adapterscapabilities to transport other protocols instead of a separate network.An example would be TCP/IP over Fibre Channel

With reference now to FIG. 2, there is depicted a block diagramillustrating a second embodiment of the system according to the presentinvention.

Correspondingly to the system of the first embodiment (FIG. 1), thepresent system comprises multiple computer systems 204, 205 and 206, allbeing adapted to access a SAN 210 via one common Fibre Channel adapter212 having WWPN 1 (World Wide Port Name). For the sake of clarity onlythree computer systems are depicted. It is acknowledged that the numberof computer systems may be in the hundreds or even in the thousands.Having such a high number of computer systems, more than one FibreChannel adapter may be present in the system, however, even in this casea plurality of computer systems would share one and the same FibreChannel adapter.

As a gateway between each of the computer systems 204, 205 and 206 andthe Fibre Channel adapter a firewall 214, 215 and 216 is provided,respectively, for ensuring that each of the computer systems is onlyenabled to access permitted portions of the SAN 210. The firewalls 214,215 and 216 may be integrated in the Fibre Channel adapter or attachedto it.

In contrary to the first embodiment, virtual servers running in avirtual server environment, such as LPAR (logically partitioned mode)plus VM (Virtual Machine), form the computer systems 204, 205 and 206.Furthermore, another virtual server 223 is provided to host a SANManagement Client 232 (SM Client). The computer systems 204, 205 and 206communicate with the SM Client 232 via a Secure Shell connection on topof Hipersockets.

A separate computer system 222 is provided for hosting a SAN ManagementServer 230 (SM Server). The SM Server 230 runs the server portion of aSAN Management System, e.g., Tivoli Storage Network Manager, whereas theSM Client 232 runs the respective client portion of such system. The SMServer 230 accesses the SM Client via an Ethernet network 220.

Each computer system 204, 205 and 206 runs an operating system 264, 265and 266, which may be “untrusted” (cf. above). The operating systemitself may be formed by any of a wide variety of operating systems, suchas AIX or z/OS by International Business Machines Corporation, UNIX andLinux.

The SM Client 232 runs on top of the HBA_API 268 (Host Bus AdapterApplication Program Interface) on top of an operating system 270, whichhas to be “trusted” (cf. above). Again, the Fibre Channel adapter 212 isadapted to distinguish untrusted and trusted operating systems. Requestsrelated to crucial Information may only be accepted coming from thetrusted operating system 270 running the SM client 232. A firewallcontrol application 234 also runs on top of the “trusted” operatingsystem 270. The firewall control application is used to instruct thefirewalls 214, 215 and 216, of whether or not to forward a particularaccess requests from the “untrusted” operating systems 264, 265 and 266to the SAN 210. In other words, only the firewall control application234, which is not accessible by any of the computer systems 204, 205 and206, is enabled to modify firewall settings specifying authorized SANaccess requests.

With reference now to FIG. 3, there is depicted a flow chartillustrating the method for operating a storage area network in a serverenvironment in which multiple servers share one Fibre Channel adapteraccording to the present invention (block 300). Firstly, the SM coreengine creates a request (block 302), and then the communication moduledetermines the target of the request (block 306). In case it is arequest for the SAN or the Fibre Channel adapter, then the communicationmodule establishes a communication path to the SM Client with respectiveauthorization data (block 308), which can be passwords, user-ids andcryptographic keys

Subsequently, the SM Client checks whether or not the authorization isvalid (block 312). If yes, the SM Client creates a response by queryingentities in the SAN such as switches (for example to retrieve a list ofFC devices in the SAN) or disk-controllers (for example to retrieve alist of logical disks in the controller) and setting the Fibre Channeladapter and SAN attributes such as RNID-ELS which is used to registerfor certain types of error notification messages (block 314).

If no, the SM Client creates a reject response informing the SM coresaid the request has been rejected (block 316). Both alternative pathscontinue by sending the response to the communication system (block318).

Going back to block 306, in case the communication module determinesthat the SM core engine created a request for the operating system (OS)configuration data, such as the fiber channel to scsi mapping defined bythe function HBAGetFcpTargetMappingFunc, the communication moduleestablishes a communication path to the RA Server with the respectiveauthorization data (block 320).

Then, the authorization component in the RA Server, for example a sshd,determines whether or not the authorization is valid (block 321) bycomparing the presented user-ids, passwords and keys to user-ids,passwords and keys, which are known by the RA Server to be authorized.

If yes, the RA Server creates a response by OS configuration operations(block 324) such as accessing the fibre channel configurationinformation stored by the fibre channel device driver of the operatingsystem.

If no, the RA Server creates a reject response (block 326). Again, bothalternatives continue by sending the response to the communicationsystem (block 318). Subsequently, the communication system forwards theresponse to the SM core engine (block 320) and the SM core engine in theSM server processes the response (block 322) as defined in the twomentioned patents.

In the following, the flow and types of requests for a preferredimplementation is shown. The syntax of HBA_API commands may be found in“Fibre Channel HBA API Working draft”(ftp://ftp.t11.org/t11/pub/fc/hba/02-268v2.pdf)

1. Firstly, the fabric and adapter related requests CT, ELS, SCSIcommands are listed. The SM client using adapter and SAN resourceshandles these commands:

-   typedef HBA_STATUS(* HBASendCTPassThruFunc) (HBA_HANDLE, void *,    HBA_UINT32, void *, HBA_UINT32);-   typedef HBA_STATUS (* HBASendRNIDFunc)(HBA_HANDLE, HBA_WWN,    HBA_WWNTYPE, void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASendScsiInquiryFunc)(HBA_HANDLE, HBA_WWN,    HBA_UINT64, HBA_UINT8, HBA_UINT32, void *, HBA_UINT32, void *,    HBA_UINT32);-   typedef HBA_STATUS (* HBASendReportLUNsFunc)(HBA_HANDLE, HBA_WWN,    void *, HBA_UINT32, void *, HBA_UINT32);-   typedef HBA_STATUS (* HBASendReadCapacityFunc)(HBA_HANDLE, HBA_WWN,    HBA_UINT64, void *, HBA_UINT32,void *, HBA_UINT32);-   typedef HBA_STATUS (* HBASendCTPassThruV2Func)(HBA_HANDLE, HBA_WWN,    void *, HBA_UINT32, void *, HBA_UINT32*);-   typedef HBA_STATUS (* HBASendRNIDV2Func) (HBA_HANDLE, HBA_WWN,    HBA_WWN, HBA_UINT32, HBA_UINT32, void *, HBA_UINT32*);-   typedef HBA_STATUS (* HBAScsiInquiryV2Func) (HBA_HANDLE, HBA_WWN,    HBA_WWN, HBA_UINT64, HBA_UINT8, HBA_UINT8, void *, HBA_UINT32 *,    HBA_UINT8 *,void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBAScsiReportLUNsV2Func)(HBA_HANDLE, HBA_WWN,    HBA_WWN, void *, HBA_UINT32 *,HBA_UINT8 *, void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBAScsiReadCapacityV2Func) (HBA_HANDLE,    HBA_WWN, HBA_WWN, HBA_UINT64, void *,HBA_UINT32 *, HBA_UINT8 *, void    *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASendRPLFunc)(HBA_HANDLE, HBA_WWN, HBA_WWN,    HBA_UINT32,HBA_UINT32, void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASendRPSFunc)(HBA_HANDLE, HBA_WWN, HBA_WWN,    HBA_UINT32, HBA_WWN,HBA_UINT32, void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASendSRLFunc)(HBA_HANDLE, HBA_WWN, HBA_WWN,    HBA_UINT32, void *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASendLIRRFunc)(HBA_HANDLE, HBA_WWN, HBA_WWN,    HBA_UINT8, RBA_UINT8,void *, HBA_UINT32 *);-   typedef HBA_HANDLE (* HBAOpenAdapterFunc)(char *);-   typedef void (* HBACloseAdapterFunc)(HBA_HANDLE);-   typedef HBA_STATUS (* HBAGetAdapterAttributesFunc)(HBA_HANDLE,    HBA_ADAPTERATTRIBUTES *);-   typedef HBA_STATUS (* HBAGetAdapterPortAttributesFunc) (HBA_HANDLE,    HBA_UINT32, HBA_PORTATTRIBUTES *);-   typedef HBA_STATUS (* HBAGetPortStatisticsFunc) (HBA_HANDLE,    HBA_UINT32, HBA_PORTSTATISTICS *);-   typedef HBA_STATUS (* HBAGetDiscoveredPortAttributesFunc)    (HBA_HANDLE, HBA_UINT32, HBA_UINT32,HBA_PORTATTRIBUTES *);-   typedef HBA_STATUS (* HBAGetPortAttributesByWWNFunc) (HBA_HANDLE,    HBA_WWN, HBA_PORTATTRIBUTES *);-   typedef void (* HBARefreshInformationFunc)(HBA_HANDLE);-   typedef void (* HBAResetStatisticsFunc)(HBA_HANDLE, HBA_UINT32);-   typedef HBA_STATUS (* HBAGetEventBufferFunc) (HBA_HANDLE,    HBA_EVENTINFO *, HBA_UINT32 *);-   typedef HBA_STATUS (* HBASetRNIDMgmtInfoFunc) (HBA_HANDLE,    HBA_MGMTINFO *);-   typedef HBA_STATUS (* HBAGetRNIDMgmtInfoFunc) (HBA_HANDLE,    HBA_MGMTINFO *);-   typedef HBA_STATUS (* HBAOpenAdapterByWWNFunc) (HBA_HANDLE *,    HBA_WWN);-   typedef void (* HBARefreshAdapterConfigurationFunc) ( );-   typedef HBA_UINT32 (*    HBAGetVendorLibraryAttributesFunc)(HBA_LIBRARYATTRIBUTES *);-   typedef HBA_STATUS (* HBAGetFC4StatisticsFunc)(HBA_HANDLE, HBA_WWN,    HBA_UINT8, HBA_FC4STATISTICS *);-   typedef HBA_STATUS (* HBAGetFCPStatisticsFunc)(HBA_HANDLE, const    HBA_SCSIID *, HBA_FC4STATIS-   typedef HBA_UINT32 (* HBAGetNumberOfAdaptersFunc)( );-   typedef HBA_STATUS (* HBAGetAdapterNameFunc)(HBA_UINT32, char *);

FIG. 4 shows a flow chart illustrating simplified signals and flow forthe aforementioned type of HBA_API commands. As apparent from FIG. 4, aSM Server communicates with a SM Client, which communicates with a FCSwitch. The SM Server, the SM Client and the FC Switch get started andrun independently from each other as illustrated by blocks 402, 404 and406. It is acknowledged that the following steps only constitute asegment of the operation, and more requests are sent or received beforeor after the method as described in the following.

Initially the SM server sends request to SM client (block 408, 410). Inthis example it is a HBASendLIRRFunc. In detail, the SM client uses theHBA API in order to send CT_IU, ELS or FCP_CMD sequences as defined bythe Fiber Channel standards FC-FS and FC-GS3 to the fabric (412,414).

The response generated in fabric as defined by the FC standards isforwarded to SM client by the completion part of the HBA_API call(418,420). The SM client forwards said response to the SM server(422,424).

2. FCP<->SCSI mapping commands

These commands are handled via a RA server using OS and OS device driverresources commands. The syntax may be found in “Fibre Channel HBA APIWorking draft” (ftp://ftp.t11.org/t11/pub/fc/hba/02-268v2.pdf)

-   typedef HBA_STATUS (* HBAGetFcpTargetMappingFunc)(HBA_HANDLE,    HBA_FCPTARGETMAPPING *);-   typedef HBA_STATUS (* HBAGetFcpPersistentBindingFunc)(HBA_HANDLE,    HBA_FCPBINDING *);-   typedef HBA_STATUS (* HBAGetBindingCapabilityFunc)(HBA_HANDLE,    HBA_WWN, HBA_BIND_CAPABILITY *);-   typedef HBA_STATUS (* HBAGetBindingSupportFunc) (HBA_HANDLE,    HBA_WWN, HBA_BIND_CAPABILITY *);-   typedef HBA_STATUS (* HBASetBindingSupportFunc) (HBA_HANDLE,    HBA_WWN, HBA_BIND_CAPABILITY);-   typedef HBA_STATUS (* HBASetPersistentBindingV2Func) (HBA_HANDLE,    HBA_WWN, const HBA_FCPBINDING2 *);-   typedef HBA_STATUS (* HBAGetPersistentBindingV2Func) (HBA_HANDLE,    HBA_WWN, HBA_FCPBINDING2 *);-   typedef HBA_STATUS (* HBARemovePersistentBindingFunc) (HBA_HANDLE,    HBA_WWN, const HBA_FCPBINDING2 *);-   typedef HBA_STATUS (*    HBARemoveAllPersistentBindingsFunc)(HBA_HANDLE, HBA_WWN);-   typedef HBA_STATUS (* HBAGetFcpTargetMappingV2Func)(HBA_HANDLE,    HBA_WWN, HBA_FCPTARGETMAPPING *);

With reference now to FIG. 5, there is depicted a flow chartillustrating simplified signals and flow for the aforementioned type ofHBA API commands. As apparent from FIG. 5, a SM Server communicatesagain with a SM Client. The SM Client, in return, communicates with aFirewall and an OS Image, respectively. The SM Server, the SM Client,the Firewall and the OS Image get started and run independently fromeach other as illustrated by blocks 502, 504, 506 and 508. It isacknowledged that the following steps only constitute a segment of theoperation, and more requests are sent or received before or after themethod as described in the following.

First, the SM server sends a request to the SM client (blocks 510, 512)for example a request with corresponds to the HBASetPersistentBindingV2HBA_API request. If the SM client has direct control over the firewallit can optionally modify the firewall (514,516,518,520) if this isrequired by the firewall security policy. The SM client then modifiesthe firewall by triggering the send-operation of a proprietary updatefirewall message (514,516).

The firewall signals completion of the operation to the SM client(518,520). Then the SM client triggers a set or query request inuntrusted OS image (526) by RA Server (522,524). The SM client waits forthe completion message of said request (528,530) SM client returns theresponse of said requests to the SM server (532,534).

3. Incoming ELSses (RNID)

These are messages, which initiate in the fabric and need to beforwarded to the SM server. These messages are used to identify thesource of problems, which occur in the SAN.

Commands defined in HBA_API to handle incoming ELSses:

-   typedef HBA_STATUS (* HBARegisterForAdapterAddEventsFunc)(void    (*)(void *, HBA_WWN, HBA_UINT32),void *,HBA_CALLBACKHANDLE *);-   typedef HBA_STATUS (* HBARegisterForAdapterEventsFunc)(void (*)(void    *, HBA_WWN, HBA_UINT32),void *,HBA_HANDLE, HBA_CALLBACKHANDLE *);-   typedef HBA_STATUS (* HBARegisterForAdapterPortEventsFunc)(void    (*)(void *, HBA_WWN, HBA_UINT32, HBA_UINT32),void *, HBA_HANDLE,    HBA_WWN, HBA_CALLBACKHANDLE *);-   typedef HBA_STATUS (* HBARegisterForLinkEventsFunc)(void (*)(void *,    HBA_WWN, HBA_UINT32, void *,HBA_UINT32),void *, void *, HBA_UINT32,    HBA_HANDLE, HBA_CALLBACKHANDLE *);-   typedef HBA_STATUS (* HBARegisterForAdapterPortStatEventsFunc)(void    (*)(void *, HBA_WWN, HBA_UINT32), void *,HBA_HANDLE, HBA_WWN,    HBA_PORTSTATISTICS,HBA_UINT32, HBA_CALLBACKHANDLE *);-   typedef HBA_STATUS (* RBARegisterForTargetEventsFunc)(void (*)(void    *, HBA_WWN, HBA_WWN, HBA_UINT32),void *, HBA_HANDLE, HBA_WWN,    HBA_WWN,HBA_CALLBACKHANDLE *, HBA_UINT32);-   typedef HBA_STATUS (* HBARemoveCallbackFunc)(HBA_CALLBACKHANDLE);

Now, with reference to FIG. 6, depicting a flow chart illustratingsimplified signals and flow for the aforementioned type of HBA_APIcommands. As apparent from FIG. 6, a SM Server communicates with a SMClient, which communicates with a FC Switch. The SM Server, the SMClient and the FC Switch get started and run independently from eachother as illustrated by blocks 602, 604 and 606. It is acknowledged thatthe following steps only constitute a segment of the operation, and morerequests are sent or received before or after the method as described inthe following.

The SM server (602) instructs the SM client (604) to register once forevents by HBA_API (608,610) and waits for the confirmation of thecompletion (612,614), untrusted OS images are not allowed to register.After this is done each message (616) created by the SAN triggers thefollowing procedure:

-   1. SM client receives event from FC adapter (616,618)-   2. SM client forwards event to SM server (620,622)

In an alternative implementation the SM client may filter and condensethe messages (616,618) to reduce the number of messages sent to the SMserver.

-   HBA_API functions which are not relevant to this invention:-   typedef HBA_UINT32 (* BAGetVersionFunc)( );-   typedef HBA_STATUS (* HBALoadLibraryFunc)( );-   typedef HBA_STATUS (* HBAFreeLibraryFunc)( );

The present invention can be realized in hardware, software, or acombination of hardware and software. Any kind of computer system—orother apparatus adapted for carrying out the methods described herein—issuited. A typical combination of hardware and software could be ageneral-purpose computer system with a computer program that, when beingloaded and executed, controls the computer system such that it carriesout the methods described herein. The present invention can also beembedded in a computer program product, which comprises all the featuresenabling the implementation of the methods described herein, andwhich—when loaded in a computer system—is able to carry out thesemethods.

Computer program means or computer program in the present context meanany expression, in any language, code or notation, of a set ofinstructions intended to cause a system having an information processingcapability to perform a particular function either directly or aftereither or both of the following a) conversion to another language, codeor notation; b) reproduction in a different material form.

1. A computer-implemented method comprising: managing a storage areanetwork (SAN) with at least a SAN Management server and a SAN Managementclient, said SAN Management client running a trusted operating systemand having a communication path to a Fibre Channel adapter, said FibreChannel adapter being disposed between the SAN and at least one computersystem running an untrusted operating system, said SAN Management serverbeing connected to the at least one computer system and the SANManagement client, said SAN Management client being further connected tothe at least one computer system, separating requests issued by the SANManagement server into at least two groups, where a first group ofrequests is issued to the SAN Management client and processed by theFibre Channel adapter and the SAN on behalf of the SAN Management clientin place of the at least one computer system, and a second group ofrequests is issued to and processed by the at least one computer systemwithout the need to send or receive requests to or from the FibreChannel adapter and the SAN, where the Fibre Channel adapter acceptsrequests relating to crucial information only from the SAN Managementclient, where the crucial information comprises information relating toat least one of a SAN configuration, a SAN component, SAN access rights,error messages, statistics or billing information, where the operationof separating the requests issued by the SAN Management server isperformed by a communication module that is distributed over the SANManagement server and the SAN Management client, maintainingauthorization data for accessing a Remote Access (RA) Server, where saidauthorization data is maintained in at least one of the SAN Managementserver and the SAN Management Client, and operating the SAN ManagementClient as a router for requests from the SAN Management server to the RAserver, wherein the RA Server comprises a telnet/sshd server, where theconnection between the SM server, the SM client and RA server is aninternet protocol (IP) based network.
 2. The method according to claim1, further comprising: routing all information contained in unsolicitedmessages generated in the SAN and Fibre Channel adapter to the SANManagement server by the SAN management client.
 3. The method accordingto claim 1, further comprising: using Host Bus Adapter_ApplicationProgram Interface binding requests to modify a firewall interposedbetween the at least one computer system and the Fibre Channel adapter,and operating the communication path from the SAN Management client tothe Fibre Channel adapter so that it cannot be modified or eavesdroppedby the at least one computer system.
 4. The method according to claim 1,further comprising: accessing all information relevant for billingindividual ones of the at least one computer system, where saidinformation is generated in the Fibre Channel adapter and the SAN andwhere said information is accessed only through the SAN Managementclient.
 5. The method according to claim 1, further comprising: said SANManagement server providing first authorization data to the SANManagement client to execute requests from said first group, and saidSAN Management server and SAN Management client providing secondauthorization data to the at least one computer system to executerequests from said second group, and operating the at least one computersystem so that it is only enabled to execute a limited command set inthe SAN.
 6. A computer program product apparatus tangibly storing acomputer readable program, where the computer readable program whenexecuted on a computer causes the computer to perform operations tomanage a storage area network (SAN), the operations comprising: managingthe SAN comprising at least a SAN Management server and a SAN Managementclient, said SAN Management client running a trusted operating systemand having a communication path to a Fibre Channel adapter, said FibreChannel adapter being disposed between the SAN and at least one computersystem running an untrusted operating system, said SAN Management serverbeing connected to the at least one computer system and the SANManagement client, said SAN Management client being further connected tothe at least one computer system, and separating requests issued by theSAN Management server into at least two groups, where a first group ofrequests is issued to the SAN Management client and processed by theFibre Channel adapter and the SAN on behalf of the SAN Management clientin place of the at least one computer system, and a second group ofrequests is issued to and processed by the at least one computer systemwithout the need to send or receive requests to or from the FibreChannel adapter and the SAN, where the Fibre Channel adapter accentsrequests relating to crucial information only from the SAN Managementclient, where the crucial information comprises information relating toat least one of a SAN configuration, a SAN component, SAN access rights,error messages, statistics or billing information, where the operationof separating the requests issued by the SAN Management server isperformed by a communication module that is distributed over the SANManagement server and the SAN Management client, further comprising anoperation of maintaining authorization data for accessing a RemoteAccess (RA) Server, where said authorization data is maintained in atleast one of the SAN Management server and the SAN Management Client,further comprising an operation of operating the SAN Management Clientas a router for requests from the SAN Management server to the RAserver, wherein the RA Server comprises a telnet/sshd server, where theconnection between the SM server, the SM client and RA server is aninternet protocol (IP) based network.
 7. The computer program productapparatus as in claim 6, further comprising an operation of: routinginformation contained in unsolicited messages generated in at least oneof the SAN and Fibre Channel adapter to the SAN Management server by theSAN management client.
 8. The computer program product apparatus as inclaim 6, further comprising an operation of: using Host BusAdapter_Application Program Interface binding requests to modify afirewall interposed between said at least one computer system and saidFibre Channel adapter.
 9. The computer program product apparatus as inclaim 6, further comprising an operation of: operating the communicationpath from the SAN Management client to the Fibre Channel adapter so thatit cannot be accessed by the at least one computer system.
 10. Thecomputer program product apparatus as in claim 6, further comprising anoperation of: accessing information relevant for billing individual onesof the at least one computer system, where said information is generatedin the Fibre Channel adapter and the SAN and where said information isaccessed only through the SAN Management client.
 11. The computerprogram product apparatus as in claim 6, further comprising an operationof: providing authorization data from the SAN Management server to theSAN Management client to execute requests from said first group ofrequests.
 12. The computer program product apparatus as in claim 6,further comprising an operation of: providing authorization data fromthe SAN Management server and the SAN Management client to the at leastone computer system to execute requests from said second group ofrequests.
 13. The computer program product apparatus as in claim 6,further comprising an operation of enabling the at least one computersystem to execute a limited command set in the SAN.
 14. A storage areanetwork (SAN) Management server, comprising: a first interfaceconfigured to couple to a SAN Management client running a trustedoperating system, said SAN Management client being further coupled to aSAN via a SAN adapter and to at least one computer system running anuntrusted operating system; and a second interface configured to coupleto the least one computer system, said at least one computer systembeing coupled to the SAN via the SAN adapter and via a unit forregulating access to the SAN; where said SAN Management server compriseslogic for distinguishing a first set of requests from a second set ofrequests, where the first set of requests is issued to the SANManagement client and processed by the SAN adapter and the SAN on behalfof said SAN Management client in place of the at least one computersystem, and where the second set of requests is issued to and processedat least in part by the at least one computer system without the need tosend or receive requests to or from the SAN adapter and the SAN, wherethe SAN adapter accepts requests relating to crucial information onlyfrom the SAN Management client, where the crucial information comprisesinformation relating to at least one of a SAN configuration, a SANcomponent, SAN access rights, error messages, statistics or billinginformation, where the operation of separating the requests issued bythe SAN Management server is performed by a communication module that isdistributed over the SAN Management server and the SAN Managementclient, where at least one of the SAN Management server and the SANManagement Client is operable to maintain authorization data foraccessing a Remote Access (RA) Server, where the SAN Management Clientis operated as a router for requests from the SAN Management server tothe RA server, wherein the RA Server comprises a telnet/sshd server,where the connection between the SM server, the SM client and RA serveris an internet protocol (IP based network.
 15. The SAN Management serveras in claim 14, where said first set of requests comprises at least oneof a SAN request and a SAN adapter request, and where said second set ofrequests comprises a request for configuration data of the at least onecomputer system.
 16. The computer program product apparatus as in claim6, where the first group of requests comprises authorized SAN accessrequests and the second group of requests comprises operating systemconfiguration requests.